transaction, before getting executed, gets validated by the selected

notary that checks all the inputs for any possible double spends.

Many Blockchain enthusiasts argue that Notary brings centralization

to Corda’s architecture; however, please note that in order to avoid a

single point of failure, we can introduce multiple notaries that can

help us in load balancing and low latency.

Please note that a Notary can be configured to be of validating or

non-validating type. In case of the validating type, the notary has to

validate the entire input data of the transaction, exposing the privacy

of the data to a third party. Most notary related configurations,

however, are of the non-validating type where it is used just to

ensure there are no double spends.

14.1.6 Time Window

With this feature, a Corda transaction can be executed with a time

constraint, i.e., before or after a particular pre-determined time. It is

highly helpful in time based contract execution.

14.1.7 Attachments

Corda also supports uploading attachment files like images, PDF

etc., in the form of Zip or JAR. This is especially helpful when the

state is associated with an official document, an image etc.

14.1.8 Contracts

In Corda, smart contracts can be written in Kotlin or Java and it can

make sure that the transaction is executed after the validation

checks. Each transaction can have zero or more inputs and outputs.

14.1.9 Interoperability with Oracles

In Corda, interoperability can be achieved by the use of Oracle

services implemented on the Oracle nodes. Some contracts may

need information from some external source before validating a

transaction. For example, the exchange price of the bond should be

more, equal, or less than the current price on a particular stock